I'm not sure what the goal of this one is? Improving the depset construction sounds good, but why is a list the correct data type here? It feels like this is a maybe-nested maybe-has-duplicates-that-need-deduplicating collection of transitive providers?

The problem is that the transitive providers can never be used efficiently as-is, because all the consumers want depsets of their nested fields, not the providers themselves. For example, cargo_build_script flattens the dep_variant_infos to extract the contained dep_infos, and then flattens each dep_info's transitive_build_infos to get the build_info.out_dir. We would need a depset of build_info_out_dirs (and similar usages) propagated on the DepVariantInfo to truly make use of the depset efficiently (Basically what we wanted was struct-of-arrays instead of array-of-structs). Given how it's actually being used in practice, there's no point wrapping the list of variant infos into a depset since every consumer just calls .to_list() on it anyway.

You're right that it could technically be transitive/duplicated if rust_library_group is nested inside another rust_library_group, though this isn't a usage I have ever come across; and in that edge case we can just dedupe/flatten once at the rust_library_group target instead of in all the consumers.